Skip to content

Support hashbrown hash maps and sets with or without use_std #1051

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

aqrln
Copy link

@aqrln aqrln commented Aug 13, 2025

Add an optional hashbrown feature that switches the underlying hash map implementation from std::collections to hashbrown and makes items that depend on hash maps available without use_std (although it still requires and implicitly enables use_alloc).

This addresses the motivating use case of #605 (which is the same use case that I am interested in) but does not implement a generic approach as the issue suggests. #901 would be a better solution long term and would make these changes obsolete, but the PR appears to be stalled and I wanted a simple solution that allows using APIs like unique/unique_by with no_std now.

It also partially addresses #322 because enabling this feature does switch to a faster hash algorithm, it just doesn't allow to specify which one exactly (currently the default hasher in hashbrown is foldhash, so this is what's going to be used until/unless changed upstream in the future).


TODO:

  • fix tests compilation with --all-features/-F hashbrown
  • run tests on CI with both hash map implementations
  • adjust contributor doc in the section about use_std

I'm opening a draft PR early because I'd like to get feedback on whether it's something you want to have.

Add an optional `hashbrown` feature that switches the underlying hash
map implementation from `std::collections` to `hashbrown` and makes
items that depend on hash maps available without `use_std` (although it
still requires and implicitly enables `use_alloc`).

This addresses the motivating use case of [rust-itertools#605][] (which is the same
use case that I am interested in) but does not implement a generic
approach as the issue suggests. [rust-itertools#901][] would be a better solution long
term and would make these changes obsolete, but the PR appears to be
stalled and I wanted a simple solution that allows using APIs like
`unique`/`unique_by` with `no_std` now.

It also partially addresses [rust-itertools#322][] because enabling this feature does
switch to *a* faster hash algorithm, it just doesn't allow to specify
which one exactly (currently the default hasher in `hashbrown` is
`foldhash`, so this is what's going to be used until/unless changed
upstream in the future).

[rust-itertools#605]: rust-itertools#605
[rust-itertools#901]: rust-itertools#901
[rust-itertools#322]: rust-itertools#322
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant